[Discuss] Sample configs for standalone Elastic Agent #6142
Conversation
Playing around with ECK and Elastic Agent I stumbled over these sample configuration files. I'm opening this issue to discuss some parts I spotted in the config file which might need adjustment. * ids: We have ids in many places but my understanding is that these are only need for the filestream input. The ids in the policy come from Fleet but are not needed in standalone mode. If these are used for some metrics reporting, I'm concerned as these are statically coded now in standalone, could it cause some unwanted side effects? * Package version: The package version is the policy but the package installed in Fleet my have a different version. It should be removed as the info is likely incorrect. * Config id and revision: Does not have an affect in standalone and might be confusing. I assume the above parts in the config come from a policy that was copied from Fleet and then put here as an example. I removed an example for each, there are more similar examples in the config. Internal Fleet information should not leak into standalone sample configs.
|
@cmacknz Would be great to get the input from you or someone on the team on this. Should we also tweak these configs further as it is likely users will use this as a default example to get running? |
| agent: | ||
| monitoring: | ||
| enabled: true | ||
| use_output: monitoring | ||
| logs: true | ||
| metrics: true | ||
| inputs: | ||
| - id: 2e187fb0-33a5-11eb-bb2f-418d0388a8cf |
There was a problem hiding this comment.
I would keep this but try to make it match what Fleet would generate. The Fleet UI generates unique IDs per input, and we should try to stay consistent between standalone and fleet policies.
A policy generated in the fleet UI would name this something like system/logfile-2e187fb0-33a5-11eb-bb2f-418d0388a8cf. The PR that added unique IDs is elastic/kibana#127343
The logfile input should work without it but there is an effort to transparently convert logfile to filestream under the hood and in that case we'll want the input and stream IDs to be unique.
|
@cmacknz I mainly opened this PR to start a discussion. Ideally I think the Elastic Agent team would own this moving forward or collaborate with the cloud-on-k8s on changes. These are the examples users get started so I assume these are seen / used pretty often. |
Agreed if these are the official getting started examples. I didn't even know these were here previously. |
I agree and thanks for taking look at these configurations. Not that it matters much but I think they were originally generated via the Fleet UI via the function where you can download the configuration and then probably modified subsequently as things changed. |
|
I think the best path for keeping these up to date is to move them into the agent repository itself, to live besides the examples for the fleet and agent documentation: https://github.com/elastic/elastic-agent/tree/main/deploy/kubernetes Probably the least disruptive option would be to just build automation that automatically opens a PR here every time they change in the agent repository. I'll investigate if that is possible. |
|
Closing since the next step is on the agent side. Thank you for starting this discussion. |
Playing around with ECK and Elastic Agent I stumbled over these sample configuration files. I'm opening this issue to discuss some parts I spotted in the config file which might need adjustment.
I assume the above parts in the config come from a policy that was copied from Fleet and then put here as an example. I removed an example for each, there are more similar examples in the config. Internal Fleet information should not leak into standalone sample configs. The same problem will likely apply to other sample configs.
The configs can be found here on our website: https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-elastic-agent-configuration-examples.html#k8s_multiple_elasticsearch_clusters_output